REMARKS 

This Request for Reconsideration is filed in response to the Office Action of 19 
July 2007. In this Request for Reconsideration, no claims have been amended, added, or 
canceled. The Applicants respectfiilly request reconsideration of the application based on 
the reasons provided herein. 

In the Office Action of 19 July 2007, the Examiner rejected claims of the patent 
application under 35 U.S.C. § 103(a) as being unpatentable over McElwain et al. (U.S. 
Patent Application Publication No. 2003/0022689A1) in view of Hicks et al (U.S. Patent 
No. 7,027,813 Al), and in further view of Makela et al. (U.S. Patent No. 7,099,687). In 
response, the Applicants respectfully disagree with the rejections and submit that all 
pending claims are allowable over the prior art of record for at least the following 
reasons. 

For a proper rejection under 35 U.S.C. § 103(a), the prior art in combination must 
teach or suggest each and every limitation of the claims. In addition, there must be some 
adequate reasoning to combine the teachings of different references. 
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1. THE FINALITY OF THE OFFICE ACTION OF 19 JULY 2007 IS 



IMPROPER SINCE THE EXAMINER'S NEW GROUNDS OF REJECTION BASED 
ON NEWLY CITED ART WERE NOT NECESSITATED BY THE APPLICANT'S 

AMENDMENTS . 

The Examiner indicates that the present Office Action of 19 July 2007 is final. 
On page 10 of the Office Action, the Examiner states that the "Applicant's amendment 
necessitated the new ground(s) of rejection presented in this Office Action. Accordingly, 
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a)." 



MPEP § 706.07(a) states that 



Under present practice, second or any subsequent 
actions on the merits shall be final, except 
where the examiner introduces a new ground of 
rejection that is neither necessitated by 
applicant's amendment of the claims . . . 

Furthermore, a second or any subsequent action on 
the merits in any application . . . will not be 



cited art 


. . of 


any 


claim not 


amended by 


applicant or 


patent 


owner 


in spite 


of the fact 


that other 


claims 


may 


have been 


amended to 



require newly cited art . (Emphasis Added) 



In the previously-submitted Amendment and Request for Reconsideration of 27 October 
2007, the Applicants amended independent claims 1 and 10 but did not amend 

independent claims 19 and 21 since the previous Office Action of 11 August 2006 failed 
to address all claim limitations. The present Office Action of 19 July 2007 includes a 
rejection based on newly cited art (e.g. Makela et al.), and is made final even though 
independent claims 19 and 21 were not previously amended by the Applicants. 

Thus, the finality of the Office Action of 19 July 2007 is improper, and the 
Applicants respectfully request for such finality to be withdrawn. 
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2. THE PRIOR ART IN COMBINATION FAILS TO TEACH OR 
SUGGEST THE STEP OF RECEIVING AN END USER INPUT TO PERFORM A 
MANUAL NETWORK SELECTION PROCEDURE AS CLAIMED . 

Independent claims 1 and 10 of the present application recite techniques which 
include "receiving, through a user interface of the mobile station, an end user input to 
perform a manual network selection procedure" (e.g. see independent method claim 1). 
In the Office Action, the Examiner states that "McEIwain teaches . . . receiving through a 
user interface of the mobile station an end user input to perform a manual network 
selection procedure (0054)." 

In the passage referenced by the Examiner (i.e. paragraph 0054 of McEIwain et 
al), it is stated that 

Further in accordance with these teachings 
the mobile station 10 may provide a visual or 
other display to the user to inform the user of 
the current service provider status. This can be 
done by displaying an alphatag, as shown by the 
following pseudo-code: 



/* giving category information to the UI based on 
what alphatag is shown by UI 

(names here are CS specific, UI uses own naming 

convention* / 

.UI_NOT_ROAMING /* Home */ 
.UI_NOT_ROAMING_PREPAID /* Cousin */ 
.UI_NOT_ROAMING_HOME_TYPE /* Partner */ 
.UI_ROAMING_SEMI_NON_HOME_TYPE /* Favored */ 
.UI_ROAMING_NON_HOME_TYPE /* Neutral */ 



As apparent from the above, there is no receipt of any end user input to perform a manual 
network selection procedure through a user interface. The above relates to the display of 
an alphatag of the current service provider, which is irrelevant to the claimed step of 
receiving. Thus, the Examiner's findings fail. 
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In McElwain et al, a conventional method for roaming control which is referred 
to as a "Preferred System Selection" is described. The Preferred System Selection 
technique relates to an automatic network selection procedure, where selection 
preferences may be estabUshed by the end user. Just because McElwain et al. states that 
"the user typically controls the system preference and mode operation through menu 
choice or selection" does not mean that such technique is a manual network selection 
procedure. As one ordinarily skilled in the art would readily appreciate, in a manual 
network selection procedure, the user is able to manually select a desired network from a 
list of available networks which are visually displayed by the mobile station. In response 
to an end user manual selection of the desired network, the mobile station registers with 
the selected network. In accordance with the claimed invention, this entire procedure is 
prompted by the end user as recited in the step of "receiving, through a user interface of 
the mobile station, an end user input to perform a manual network selection procedure." 

The prior art of record, including McElwain et al.. Hicks et al. and Makela et al., 
do not teach or suggestion these limitations. If the Examiner is making any inherency 
arguments, the Examiner has failed to establish a prima facie case under 35 U.S.C. § 
103(a) since any inherent teachings must necessarily be present in the prior art and the 
Examiner must articulate reasoning related to the same. The Applicant respectfully 
submits that such teachings as claimed are not present in the prior art of record. 

Near the end of the Office Action, the Examiner asserts with respect to all 
rejections that 

The references made herein are done so for the 
convenience of the applicant. They are in no way 
meant to limit the reference. The reference must 

be considered in its entirety. 

In response, the Applicants respectfully note that the Examiner has a duty to articulate 
claim rejections with specificity and adequate reasoning. Otherwise, the rejection fails. 
It is difficult if not impossible for the Applicants to adequately respond to a vague and 
vinclear rejection of claims. This is especially true in the present case where the 
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Examiner is incorporating the disparate teachings of three (3) different references in an 
obviousness rejection. Further, if the Examiner is making any inherency arguments, any 
inherent teachings must necessarily be present in the prior art and the Examiner must 
articulate reasoning related to the same. 

Based on the above, the Applicants respectfully request the Examiner to withdraw 
the improper claim rejections and allow the application. 
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3. THE PRIOR ART IN COMBINATION FAILS TO TEACH OR 



SUGGEST THE STEP OF RETRIEVING A PLURALITY OF NETWORK 
IDENTIFIERS CORRESPONDING TO THE PLURALITY OF IDENTIFIED 
COMMUNICATION NETWORKS IN ACCORDANCE WITH AN ENHANCED 
OPERATOR NAME STRING (EONS) PROTOCOL AS CLAIMED . 

All claims of the present application recite a technique which includes "retrieving 
a plurality of network identifiers corresponding to the plurality of identified 
communication networks in accordance with an Enhanced Operator Name String (EONS) 
protocol" (see e.g. claim 1) or the like. In the rejection of claims, the Examiner states 
that "McElwain teaches . . . retrieving a plurality of network identifiers corresponding to 
the plurality of identified communication networks (0054)." In addition, the Examiner 
states that "McElwain fails teach retrieving a plurality of network identifiers 
corresponding to the plurality of communication networks in accordance with an 
Enhanced Operator Name String (EONS) protocol. However, Hicks teaches retrieving a 
plurality of network identifiers corresponding to the plurality of communication networks 
in accordance with an Enhanced Operator Name String (EONS) protocol (col 1 lines 64- 
67, col 2 lines 1-10)." 

In the passage of McElwain et al. referenced by the Examiner (i.e. paragraph 0054 
of McElwain et al.), it is stated that 

Further in accordance with these teachings 
the mobile station 10 may provide a visual or 
other display to the user to inform the user of 
the current service provider status. This can be 
done by displaying an alphatag, as shown by the 
following pseudo-code: 



/* giving category information to the UI based on 
what alphatag is shown by UI 

(names here are CS specific, UI uses own naming 
convention*/ 

.UI_NOT_ROAMING /* Home */ 
.UI_NOT_ROAMING_PREPAID /* Cousin */ 
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.UI_NOT_ROAMING_HOME_TYPE /* Partner */ 
.UI_ROAMING_SEMI_NON_HOME_TYPE /* Favored */ 
.UI_ROAMING_NON_HOME_TYPE /* Neutral */ 



As indicated above, it is stated that "mobile station 10 may provide a visual or other 
display to inform the user of the current service provider status." However, this does not 
teach a plurality of network identifiers that are retrieved based on a plurality of scanned 
and available networks. Rather, this teaching relates to a single network identifier that is 
retrieved merely for a single currently registered network. The claimed step is not even 
performed in, during, or for any manual network selection procedure. 

As apparent, although the patent publication of McElwain et al. happens to 
visually illustrate a plurality of category types based on what alphatag is shown by the 
user interface, the mobile terminal of McElwain ct al. does not retrieve the plurality of 
category types for multiple networks identified from a scanning process; rather it merely 
utilizes the category information for retrieving a single network identification (i.e. the 
ciirrently registered network). 

The Hicks et al. reference fails to make up for such deficiency. The passage in 
Hicks et al. that the Examiner refers to relates to the conventional usage of EONS. In 
column 2 at lines 3-6, for example. Hicks et al. states that 

The E-ONS feature is intended to provide an 
algorithm for determining what to display on the 
mobile's display with respect to the current 
service provider information via an alphanumeric 
tag on the mobile user interface. (Emphasis 
Added) 

Thus, Hicks et al. fails for the same reasons as the McElwain et al. reference with respect 
to the step of "retrieving a plurality of netw ork identifiers corresponding to the plurality 
of identified communication networks in accordance with an Enhanced Operator Name 
String (EONS) protocol" (see e.g. claim 1). 
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Near the end of the Office Action, the Examiner asserts with respect to all 
rejections that 

The references made herein are done so for the 
convenience of the applicant. They are in no way- 
meant to limit the reference. The reference must 

be considered in its entirety. 

In response, the Applicants respectfully note that the Examiner has a duty to articulate 
claim rejections with specificity and adequate reasoning. Otherwise, the rejection fails. 
It is difficult if not impossible for any Applicant to adequately respond to a vague and 
unclear rejection of claims. This is especially true in the present case where the 
Examiner is incorporating the disparate teachings of three (3) different references in an 
obviousness rejection. Further, if the Examiner is making any inherency arguments, any 
inherent teachings must necessarily be present in the prior art and the Examiner must 
articulate reasoning related to the same. 

Based on the above, the Applicants respectfijUy request the Examiner to withdraw 
the improper claim rejections and allow the application. 
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4. THE PRIOR ART IN COMBINATION FAILS TO TEACH OR 
SUGGEST THE STEP OF VISUALLY DISPLAYING THE PLURALITY OF 
NETWORK IDENTIFIERS RETRIEVED IN ACCORDANCE WITH THE EONS 
PROTOCOL . 

All claims of the present application recite a technique which includes "visually 
displaying the plurality of network identifiers retrieved" which occurs "in the manual 
network selection procedure" (see e.g. claim 1) or the like. In independent claims 19 and 
21, for example, the technique includes "simultaneously visually displaying the plurality 
of network identifiers." 

In the Office Action, the Examiner states that "McElwain teaches ... visual 
displaying the plurality of network identifiers retrieved (0054)." In the passage 
referenced by the Examiner (i.e. paragraph 0054 of McElwain et al.), it is stated that 



Further in accordance with these teachings 
the mobile station 10 may provide a visual or 
other display to the user to inform the user of 
the current service provider status. This can be 
done by displaying an alphatag, as shown by the 
following pseudo-code: 



/* giving category information to the UI based on 
what alphatag is shown by UI 

(names here are CS specific, UI uses own naming 
convention*/ 

.UI_NOT_ROAMING /* Home */ 
.UI_NOT_ROAMING_PREPAID /* Cousin */ 
.UI_NOT_ROAMING_HOME_TYPE /* Partner */ 
.UI_ROAMING_SEMI_NON_HOME_TYPE /* Favored */ 
.UI_ROAMING_NON_HOME_TYPE /* Neutral */ 



As indicated above, it is stated that "mobile station 10 may provide a visual or other 
display to inform the user of the current service provider status." However, this does not 
teach a pliarality of network identifiers that are visually displayed based on the scanned 
available networks for a manual network selection procedure. Rather, this teaching 
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relates to the network identifier that is displayed merely for a single currently registered 
network. The claimed step is not even performed in, during, or for any manual network 
selection procedure. 

As apparent, although the patent publication of McEIwain et al. happens to 
visually illustrate a plurality of category types based on what alphatag is shown by the 
user interface, the mobile terminal of McEIwain et al. does not visually display the 
plurality of category types for multiple networks simultaneously; rather, it merely utilizes 
the plurality of category types for displaying a single network identification at a time (i.e. 
the currently registered network). Thus, the Examiner's findings fail. 

Relatedly, the Examiner utiHzes the Makela et al. reference for allegedly teaching 
"a user manual network selection (col 10 lines 12-67, col 11 lines 1-5)." In the passage 
referenced by the Examiner, in column 10 at lines 63-66, it is stated that "[i]t may form a 
message to be shown on the display of the mobile terminal to inform the user about the 
suggested bearer service, or possibly a list of bearer services that may be selected." This 
display of the list in Makela et al. does not, however, teach, suggest, or render obvious 
the step of "visually displaying the plurality of network identifiers retrieved." For one, 
the display of the "list of bearer services that may be selected" is a list based on a bearer 
service reply network message received from the network - not from networks identified 
from scanning. Note that it is not even explicit in Makela et al. where any scanning is 
performed to identify available networks. Further, the display of the "list of bearer 
services that may be selected" of Makela et al. is far removed from the actual fully- 
claimed step of "visually displaying the plurality of network identifiers retrieved in 
accordance with the EONS protocol" (e.g. see claim 1). For example, it has not been 
demonstrated, articulated, or reasoned why the teachings of Hicks et al. (i.e. the teachings 
of EONS) would be incorporated with the teachings of Makela et al. (as opposed to 
McEIwain et al.). 

Near the end of the Office Action, the Examiner asserts with respect to all 
rejections that 
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The references made herein are done so for the 
convenience of the applicant. They are in no way 
meant to limit the reference. The reference must 
be considered in its entirety. 

In response, the Applicants respectfully note that the Examiner has a duty to articulate 
claim rejections with specificity and adequate reasoning. Otherwise, the rejection fails. 
It is difficult if not impossible for any AppHcant to adequately respond to a vague and 
unclear rejection of claims. This is especially true in the present case where the 
Examiner is incorporating the disparate teachings of three (3) different references in an 
obviousness rejection. Further, if the Examiner is making any inherency arguments, any 
inherent teachings must necessarily be present in the prior art and the Examiner must 
articulate reasoning related to the same. 

Based on the above, the Applicants respectfully request the Examiner to withdraw 
the improper claim rejections and allow the application. 
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5. THE PRIOR ART IN COMBINATION FAILS TO TEACH ONE OR 



MORE OF THE CLAIMED STEPS WHICH OCCUR IN OR DURING A MANUAL 
NETWORK SELECTION PROCEDURE . 

Claims of the present application recite that particular steps occur "in" or "during" 
a manual network selection procedure. In independent method claim 1, for example, it is 
recited that the steps of "scanning," "retrieving," "visually displaying," and "receiving" 
occur "in the manual network selection procedure." Deliberate use of a colon ": " is 
provided after the limitation "in the manual network selection procedure," and the 
subsequently claimed steps fall within the scope of this procedure through deliberate use 
of indentation of these steps. If the Examiner is broadly interpreting the claim language 
in a different manner, then the Examiner's interpretation is unreasonable. Independent 
claims 10, 19, and 21 are worded and structured differently fi-om claim 1, but the same or 
similar interpretation principles apply. 

The prior art fails to teach that one or more of these steps occur in or during a 
manual network selection procedure, especially one that is triggered by receipt of an end 
user input to perform the procedure (e.g. see claims 1 and 10). For example, the 
Examiner asserts that the McElwain et al. reference teaches or suggests the step of 
"scanning" and, even assuming arguendo that it does, this step of scanning does not 
occiar in or during any manual network selection procedure. As another example, the 
Examiner asserts that the Hicks et al. reference teaches or suggests the step of 
"retrieving" and, even assuming arguendo that it does, this step of retrieving does not 
occiar in or during any manual network selection procedure even when the teachings of 
McElwain et al. and Hicks et al. are combined. 

Thus, the Applicants respectfiilly request the Examiner to withdraw the improper 
claim rejections and allow the application. 
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Based on the reasons presented herein, the Applicants respectfully request the 
Examiner to withdraw all § 103 rejections and allow all pending claims 1-24. The 
Applicants respectfully submit that the present application is now in a condition suitable 
for allowance based on the reasons presented herein. 

Thank you. The Examiner is welcome to contact the undersigned if necessary to 
expedite prosecution of the present apphcation. 



RespectfijUy submitted, 



/John J. Oskorep/ 



Date: 20 September 2007 JOHN J. OSKOREP 

Reg. No. 41,234 

JOHN J. OSKOREP, ESQ. LLC 
ONE MAGNIFICENT MILE CENTER 
980 N. MICHIGAN AVENUE, SUITE 1400 
CHICAGO, ILLINOIS 60611 USA 

Telephone: (312) 222-1860 Fax: (312)475-1850 
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